1. Field of the Invention
This invention relates to data storage systems and more particularly relates to the autonomic expansion and virtualization of data storage servers.
2. Description of the Related Art
Modern technology has led to the heavy reliance of businesses on electrical data storage systems. These storage systems are used to backup and archive critical information that must be stored and retrieved quickly and reliably. Typically, a storage system includes a remote server or group of servers that are accessible by any number of clients across a common network. The storage servers may utilize storage devices such as magnetic disks, optical disks, and magnetic tape subsystems to store vast amounts of operational, backup, and archive data for the clients. Management software is typically used to configure a maintenance database that records metadata describing the files stored on backend storage devices. Typically, these maintenance databases identify a file location, which client the file belongs to, and the date a file was stored, created, or modified. These maintenance databases may have a limited size defined by the management software being used. Typically, a new maintenance database must be created when one of the existing maintenance databases reaches its capacity. This usually requires the manual configuration of a new server as well as the reconfiguration of each affected client which may result in high monetary costs and a loss of production.
In one embodiment, TSM (Tivoli Storage Manager) software, provided by IBM of Armonk, N.Y., is used to manage a backup or archive system by maintaining a maintenance database of the files stored on a particular server. A TSM server maintenance database may have an upper size limit of 530 Gigabytes, and for best performance and maintainability, may be limited to approximately 100 Gigabytes. The size of a maintenance database is calculated by determining the number of files that will fill a given configuration and multiplying that value by the size of each entry. Assuming no storage pool backups will be required and no files are aggregated, the size of a typical maintenance database entry is approximately 600 bytes, although this number could vary due to file size or file name. Therefore, a server with 12 Terabytes of storage and an average file size of 10 Kilobytes will require an 840 Gigabyte maintenance database which exceeds the 530 Gigabyte limit.
In another embodiment, maintenance database size is figured as a percentage of the total storage space available. Using TSM software, the maintenance database size limit is typically one to five percent of the total storage capacity. The tables provided below list the maintenance database size requirements for various storage capacities.
Maintenance database Size RequirementsCalculations using 600 bytes/fileTotal Backend Storage3 TB6 TB12 TB21 TB48 TBAverage File Size 10 KB210GB*420GB*840GB**1.47TB**3.36TB**100 KB21GB42GB84GB147GB*336GB*250 KB8.4GB16.8GB33.6GB58.8GB134.4GB*500 KB4.2GB8.4GB16.8GB29.4GB67.2GB 1 MB2.1GB4.2GB8.4GB14.7GB33.6GB 2 MB1.05GB2.1GB4.2GB7.35GB16.8GB
Maintenance database size requirementsCalculations using % of storage capacityTotal Backend Storage3 TB6 TB12 TB21 TB48 TB1% 30 GB60 GB120 GB* 210 GB*480 GB*5%150 GB300 GB*600 GB** 1.2 TB** 2.4 TB***Exceeds TSM's practical maintenance database size limit of 100 GB**Exceeds TSM's maximum maintenance database size limit of 530 GB
As demonstrated in the tables above, a single maintenance database is insufficient in many cases to manage a large storage area. In a typical archive environment, these maintenance databases may reach their maximum capacity or exceed their ideal operating capacity. Particularly in a data retention environment, the data could be retained for long periods of time, thereby not freeing up maintenance database space and leading to size and efficiency problems. Currently, the remedy for these problems is to manually configure new servers with new maintenance databases, and then bring these new servers online which can be extremely costly in terms of money and production.
FIG. 1 is a schematic block diagram illustrating a conventional data storage system 10. A Client 12 connects to a server instance 14. The server instance 14 accesses the back end storage 16 and includes a maintenance database 18. The Client 12, in various embodiments, may comprise a personal computer, workstation, laptop or other device as will be recognized by one skilled in the art. The back end storage 16 may include disk storage devices, tape storage devices, a storage sub-system, or other storage devices or combination of storage devices as will be recognized by one skilled in the art. Maintenance database 18 is used to store metadata corresponding to the data stored in the back end storage 16. The metadata, in one embodiment, may include information such as file name, location, and size, as well as dates the file was stored or accessed.
The server instance 14 may service multiple clients and may service storage operations for each of them. The client 12 may be connected to the server instance 14 through a local area network (LAN), and the server instance 14 maybe connected to the back end storage 16 through a storage area network (SAN). As described above, one problem with current configurations is that the maintenance database 18 may reach or exceed a capacity threshold requiring the manual implementation of a new server and maintenance database.
From the foregoing discussion, it should be apparent that a need exists for an apparatus, system, and method that autonomically virtualizes a data storage server by creating new server instances and maintenance databases as needed. Beneficially, such an apparatus, system, and method would increase the performance and reliability of the system, eliminate maintenance database size limit problems, and significantly reduce the number of manual configuration steps required to expand the storage system.